1. Field of the Invention
The invention relates to a method for interchanging data between two devices in a network, where the method uses a communication protocol having an interface conforming to the OPC-UA standard for the purpose of interchanging the data. The invention also relates to an apparatus for interchanging data between two devices as well as to a network having at least two devices and such an apparatus.
2. Description of the Related Art
Crevatin, M. et al., “Security for Industrial Communication Systems”, Proceedings of the IEEE, Vol. 93, No. 6, Jun. 1, 2005, pages 1152-1177 (“Crevatin”), describes a method for exchanging data between two devices in a network, where the method communication protocol having an interface conforming to the OPC standard for the purpose of interchanging the data. In dependently thereof, Crevatin mentions the use of IEEE 802.IQ VLAN and priority schemes to enable fast transmission of data with a very low time delay for time-critical applications by bypassing IP layers.
WO 2007/105979 A1 cites, in connection with a synchronization of a software agent with a system cycle in an automation system, an OPC-UA (United Architecture) interface to allow web-based access to parts of an automation system.
FIG. 1 shows a schematic representation of an automation network. A plurality of devices 8 that receive data from sensors 10 and output suitable control data to actuators 9 are located on what is termed the field level of an industrial automation system. Within this scheme the devices 8 can be in operative contact with the sensors 10 and actuators 9 as autonomous computers, or the devices 8 can be embedded systems. In particular, the devices 8 can possess their own individual control firmware. Additionally shown by way of example is a computer 7 that is present at the control level (PLC). The computer 7 and the devices 8 are used for open- or closed-loop control of associated machines of an installation. Within the automation network they reside on the subnetworks of the networks referred to as the field network 4 or plant floor network 3.
A link is formed between the plant floor network 3 and an automation network 2 by way of a computer 6 having a supervisory control and data acquisition (SCADA) system. The computer 6 is thus part of the process control level by which technical processes in the plant floor network 3 and field network 4 are monitored and controlled.
A computer 5 can be provided at a higher hierarchical level of the automation network as part of an enterprise network 1. The computer 5 can contain a manufacturing execution system (MES) and thus be part of the plant control level. Alternatively, the computer 5 can be equipped with an enterprise resource planning (ERP) system as part of the enterprise level, where the ERP system deployed at the office level constitutes a complex software suite for supporting the resource planning of an enterprise (e.g., an SAP system).
It is usual practice to deploy non-realtime-capable star systems for network communication at the office level. The Object Linking and Embedding for Process Control (OPC) Unified Architecture (OPC-UA) system according to the specifications of the OPC Foundation has established itself here as the new standard in network communications between the SCADA system of the computer 6 and the ERP system of the computer 5. In data communication according to OPC-UA, data (values) is assigned a quality that also includes the rate at which the value is to be updated. Only such data is transmitted that has changed and whose attributes initiate the necessity for the respective value to be transmitted. Accordingly, OPC-UA provides event-based communication. In this regard, OPC-UA is based on a remote procedure call (RPC) mechanism, as is known for example in standard Ethernet, TCP/IP (Transmission Control Protocol/Internet Protocol) or also http-based networks. According to the RPC mechanism, a request by a client on a server leads to a procedure being called on the server for the purpose of processing the request. Only when the processing of the request has been completed and a response has been sent from the server to the client, can the server continue the process that was interrupted by the request. This is the classic communications architecture of inter-process communication (IPC) in distributed systems. Concurrently running processes are causally dependent on one another.
OPC-UA, in contrast, knows the mechanism of what are referred to as subscriptions. In this scheme, a receiver takes out a subscription to receive a specific selection of information or data from a sender. If the set of information or selection of data is subsequently changed, the sender will independently send the changes to the receiver. This mechanism can be parameterized, because it can be specified, for example, at what time interval at the earliest changes are to be sent.
With OPC-UA, the industry has available to it a standard protocol with the aid of which it is possible, on the one hand, to model the most disparate forms of information (alarms or process values) in an information model and, on the other hand also, to transport the information. For this purpose there are service sets and services, as they are called, which make the corresponding functionalities available. With OPC-UA, it is possible for the first time to utilize this convenient form of information transmission in the embedded sector also. This makes OPC-UA a powerful tool in the information modeling field.
Whereas OPC-UA is currently used mainly in the automation network 2, for example, in SCADA systems, other requirements entirely are expected to be fulfilled by the communication protocols in the plant floor network 3 and/or field network 4. In the automation environment, it is necessary to synchronize a plurality of devices 8 via communication links. The requirements to be met by the synchronization are very diverse. They extend as far as hard realtime requirements, for example, with respect to the synchronization of drive shafts in a paper mill. In particular on the plant floor, where the field level meets the office level, Ethernet TCP/IP-based infrastructures are often already in use, for example, for communication between head controllers and/or SCADA/MES systems.
In these cases, it is usual to employ what are known as clocked protocols. This means that the time is subdivided into time slices and it is planned precisely in advance which device may send, how and how much, within one timing cycle. Cyclic process maps (tables containing input-output values) are exchanged between the communication partners. The following rule applies here: The shorter the cycle (higher clock rate), the better is the synchronization capability and the more data must be continuously transmitted. A doubling of the clock rate leads to the doubling of the overall communication volume. All the data is always sent in each cycle, irrespective of whether the same time requirements apply to all the values or whether values have changed. This communication principle is usual on the field level in automation technology to ensure that the hard realtime requirements that prevail there can be fulfilled.
In the decentralized peripherals environment, realtime communication can in this case occur, for example, by way of the Profinet IO communication protocol. This enables data interchange between Ethernet-based field devices 8. A further Ethernet-based approach for automation technology is Industrial Real Time Ethernet (IRTE). According to IRTE, communication on the network is preplanned completely to rule out unwanted data collisions. However, this model is very static, because it is unable to respond to changes without new planning. The planning is highly complex and can only be accomplished with the aid of a tool, because time responses due, for example, to cable lengths must also be taken into account. IRTE is primarily used for planning line structures. The advantage consists in strict determinism being established.
As a result, the office and/or control level and the field level are separated in terms of the communication protocols used in their subnetworks. The communication protocols used in each case satisfy different requirements. In certain situations, the realtime requirements prevailing on the field level may be irrelevant to the office level. The expression “vertical integration of automation technology” is understood to mean the aspiration to integrate the different subnetworks and create a standardized communications structure from the enterprise level right down to the field level.
Hard realtime requirements exist in many fields of application of automation technology, for example, when shafts are to be synchronized with a high degree of precision. In hard realtime scenarios, data must be interchanged between two devices within a predefined time period. Communication occurs strictly deterministically. If data is interchanged outside of a specified time interval, the data no longer fulfills the realtime requirements. What is to be understood to mean by realtime is defined in particular in DIN 44300.
In the case of soft realtime requirements, the conditions imposed on the temporal progression of the data interchange are less stringent. It is simply necessary to ensure that the data interchange between two devices is completed within a predetermined time period with a predefined probability. For example, it can be provided that, with regard to a distribution of the time instants at which the data interchange occurs, the average value of the distribution always lies within a predefined time interval. Soft realtime requirements are sufficient in many fields of application of automation technology. This is the case primarily when, owing to the nature of the automation task in hand, the requirements are not so time-critical.
Accordingly, approaches exist for communication protocols that fulfill soft realtime requirements, such as Soft Real Time (SRT) Ethernet. In the case of SRT, Ethernet priority mechanisms are used to make conventional Ethernet and/or TCP/IP communication soft-realtime-capable and thus enable the communication to occur in addition to the conventional data traffic. In the case of SRT, collisions between data packets, although avoided, are not ruled out completely. It is not necessary to preplan communications on the network completely. For example, the time response of the data packets must not necessarily be planned, but only the paths for the prioritized communication. As is usual practice in the case of Ethernet or office communication, star structures can be planned.